System and method for testing devices

ABSTRACT

A system and method for providing seamless communication with threads executing on an embedded computer. Using a DAT system, a programmer can test the communication interfaces of a thread via either a scripting program, any COM-compliant program, or a graphical test utility. The DAT system automatically formats a block of data that is transmitted between the embedded computer and a host computer and accounts for machine specific enumeration sizes, machine specific pointer sizes, machine specific structure alignment boundaries, machine specific integer sizes, and machine specific byte ordering.

RELATED APPLICATIONS

This application is continuation of U.S. patent application Ser. No.11/061,283, filed Feb. 18, 2005, which is a continuation-in-part of thefollowing commonly owned patent applications: U.S. patent applicationSer. No. 10/105,061, titled “System and method for formatting data fortransmission between an embedded computer and a host computer havingdifferent machine characteristics,” filed Mar. 22, 2002, now U.S. Pat.No. 7,111,302; U.S. patent application Ser. No. 10/104,989, titled“System and method for building a database defining a plurality ofcommunication interfaces,” filed Mar. 22, 2002, now U.S. Pat. No.7,359,911; U.S. patent application Ser. No. 10/104,985, titled “Systemand method for providing an interface for scripting programs tocommunicate with embedded systems,” filed Mar. 22, 2002, now U.S. Pat.No. 7,062,772; U.S. patent application Ser. No. 10/105,062, titled“System and method for providing an interface for COM-compliantapplications to communicate with embedded systems,” filed Mar. 22, 2002;and U.S. patent application Ser. No. 10/105,069, titled “System andmethod for generating data sets for testing embedded systems,” filedMar. 22, 2002, now U.S. Pat. No. 7,237,230.

Each of the foregoing priority applications for which Applicant No.11/061,283 is a continuation-in-part of claims the benefit of thefollowing applications: U.S. Provisional Application No. 60/278,212,filed Mar. 23, 2001, titled “System for debugging and tracing theperformance of software targeted for embedded systems” and U.S.Provisional Application No. 60/299,555, filed Jun. 19, 2001, titled“Messaging system and process”, and U.S. Provisional Application No.60/363,436, filed Mar. 11, 2002, titled “Development and testing systemand method.”

All of the above-referenced applications are herein incorporated byreference in their entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The field of the invention relates to development and testing. Moreparticularly, the field of the invention relates to the development andtesting of software.

2. Description of the Related Technology

An embedded device typically includes a microprocessor and applicationsoftware. The application software runs under the control of a real-timeoperating system (RTOS) and is typically partitioned into one or morethreads. A thread is an independent unit of executable software thatshares the control of the microprocessor with other defined threadswithin the embedded system. In many embedded devices, a thread isallocated its own stack space, given a “priority”, and assigned otherresources that enable the thread to run as an “independent” entity.Stack space is a section of memory reserved for temporary storage oflocal variables. Priorities are used by the RTOS to determine whichthread gets control of the microprocessor if more than one thread iswaiting. Resources can include miscellaneous items such as queues,flags, etc., that are required by the RTOS to manage a thread. Othercommon terms used for a thread are “task” and “process.” A process alsoimplies a separate address space which protects different processes fromadversely affecting each other. An example of a process running on adesktop computer using Microsoft's Windows Operating System (OS) isMicrosoft Word.

A common method for threads to communicate with each other is via amessaging application programming interface (API) that is provided bythe operating system. A message typically includes an event andoptionally a block of data that is sent between at least two threads.For example, a thread (“the sender”) builds a message and invokes aspecific API from the RTOS. The RTOS notifies the other thread (“thereceiver”) that some type of event has occurred. The receiving threadthen reads the incoming message. Another common method for threads tocommunicate is via a function call. Using a function call provided byone thread can be invoked by another thread. Likewise functions can becalled by other functions that co-exist in the same thread. Other commonterms for a function include a subroutine, a procedure, or a method. Asused herein, the term “communication interface” is intended to embraceany interface for communicating data between two threads, such as viaeither messaging or remote function call communication.

There are several problems associated with known development and testingsystems for embedded devices as described above. First, known testingsystems require the use of the embedded device that has an operationalRTOS to test the communication interfaces of the threads and to test theexecution of the threads themselves. Disadvantageously, known systems donot have the ability to simulate communication interfaces and thecorresponding threads that support them.

Second, when using more than one platform to host running threads, thereis a compatibility problem representing interfaces on differentmachines. Different types of machines store messages differently intheir respective memory space. Known testing systems do notautomatically format data for transmission to different platforms. Anexample of incompatibility between two computers is when one computerstores a 16-bit integer (2 bytes) with the least significant byte in lowmemory (Little Endian) and the other computer stores the leastsignificant byte in high memory (Big Endian). When the applications wantto exchange this 16-bit integer, the value of the integer is interpreteddifferently depending on the computer.

Third, known systems require the creation of a custom desktop tool thatcan communicate with the embedded software. The process of buildinginterface functionality for a specific embedded application is a timeconsuming and manual process. The desktop tool and the embedded softwareboth require manual updates to their application to enable them tocommunicate with each other. Thus, there is no seamless and automaticaccess via a desktop tool to the interfaces for an embedded softwareapplication.

Fourth, desktop applications developed in other programming languagesthat are incompatible with standard C/C++ interface definition filescannot interact with the embedded computer seamlessly. Typically,interface definition files define the format of the messages expected bythe embedded software. Languages such as Visual Basic, LabVIEW, etc.,cannot use standard C interface definition files that define the formatof the interfaces. Thus, software engineers that use these languagescannot test the threads executing on the embedded device.

Thus, there is a need for improved devices for development and testingof embedded software that do not have the foregoing limitations.

SUMMARY OF THE INVENTION

One embodiment comprises a method. The method may include transmitting arequest from a host device to a target device to intercept a call froman invoking routine to an invoked routine; intercepting the call;collecting at least one parameter that is provided as part of the callto the invoked routine; transmitting the parameter from the targetdevice to the host device; and modifying the parameter based upon acharacteristic of the host device and the target device.

Another embodiment comprises a system. The system may comprise a targetdevice; and a host device configured to transmit to the target device arequest to intercept an call from an invoking routine to an invokedroutine, the target device configured to intercept the call and collectat least one parameter that parameter that is provided as part of thecall, the target device configured to transmit the parameter from thetarget device to the host device; and the target device configured tomodify the parameter based upon a characteristic of the host device andthe target device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a development and testing systemfor testing an embedded computer.

FIG. 2 is a block diagram illustrating certain components of acommunication database that is part of the development and testingsystem of FIG. 1.

FIG. 3 is a block diagram illustrating another embodiment of thedevelopment and testing system of FIG. 1.

FIGS. 4A and 4B are a diagram of an exemplary script that can be used tocommunicate with the embedded computer of FIG. 3.

FIG. 5 is a block diagram illustrating another embodiment of thedevelopment and testing system of FIG. 1.

FIG. 6 is a block diagram illustrating the exemplary contents of thecommunication database of FIG. 1.

FIG. 7 is a block diagram illustrating an exemplary object hierarchy ofthe generated component of FIG. 5.

FIG. 8 is a flowchart illustrating a process of modifying a source filefor use with the development and testing system of FIG. 1.

FIG. 9 is a flowchart illustrating a process of building thecommunication database of FIG. 1.

FIG. 10 is a flowchart illustrating a process of using the host platformcommunication module of FIG. 1.

FIG. 11 is a flowchart illustrating a process of formatting acommunication.

FIGS. 12A-12D illustrate exemplary methods of managing pointer data whentransmitting the pointer data between two platforms having differentmachine characteristics.

FIG. 13 is a flowchart illustrating a process of using a scripting fileto communicate with threads executing on the embedded computer.

FIG. 14 is a flowchart illustrating a process of loading the messagingautomation component of FIG. 3.

FIG. 15 is a flowchart illustrating a process of registering a threadexecuting in a script with the development and testing system of FIG. 3.

FIG. 16A is a flowchart illustrating a process of sending a messagecommunication from a script to the development and testing system ofFIG. 3.

FIG. 16B is a flowchart illustrating a process of sending a invoking afunction call from a script to the development and testing system ofFIG. 3.

FIG. 17A is a flowchart illustrating a process of a script receiving amessage via a script from the development and testing system of FIG. 3.

FIG. 17B is a flowchart illustrating a process of a script receiving acommunication via remote function call from the development and testingsystem of FIG. 3.

FIG. 18 is a flowchart illustrating a process of utilizing the generatedcomponent of FIG. 5.

FIG. 19 is a flowchart illustrating a process of launching the COMcomposer of FIG. 5.

FIG. 20 is a flowchart illustrating a process of building the generatedcomponent of FIG. 5.

FIG. 21 is a flowchart illustrating a process of generating an interfaceof the generated component of FIG. 1.

FIG. 22 is a flowchart illustrating a process of using the generatedcomponent of FIG. 5 from any COM-compliant language.

FIG. 23 is a flowchart illustrating a process of testing one of thecommunication interfaces that is identified by the communicationdatabase of FIG. 1.

FIG. 24 is a flowchart illustrating a process of generating data sets ofinformation based upon monitoring communications that are transmittedbetween at least two threads.

FIG. 25 is an exemplary user interface for testing messages.

FIG. 26 is an exemplary user interface for testing remote functioncalls.

FIG. 27 is a flowchart illustrating a process of generating templatecode for use with the development and testing system of FIG. 1.

FIG. 28 is a flowchart illustrating a process of generating code forhandling a message that is defined by a predefined communicationinterface.

FIG. 29 is a flowchart illustrating a process of generating messagehandling code.

FIG. 30 is a flowchart illustrating a process of generating code to senda message to a predefined communication interface.

FIG. 31 is a flowchart illustrating a process of generating code forhandling inter-platform messaging in response to a function call.

FIG. 32 is a block diagram illustrating exemplary generated code.

FIG. 33 is a block diagram illustrating exemplary generated code.

FIG. 34 is a flowchart illustrating a process of generating and usingcode to intercept selected routines executing on a target device.

FIG. 35 is a flowchart illustrating a process of generating interceptioncode that occurs in one embodiment during the process of FIG. 34.

FIG. 36 is a flowchart illustrating a process of generating a proxy thatoccurs in one embodiment during the process of FIG. 35.

FIG. 37 is a flowchart illustrating a process of generating code tointercept an routine that executed by a target device.

FIG. 38 is a graphical user interface used to receive module informationto be able to perform the process of 35.

FIG. 39 is a graphical user interface used to receive instructions froma user defining the types of interception that are to be performed.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS OF THE INVENTION

The following detailed description is directed to certain specificembodiments of the invention. However, the invention can be embodied ina multitude of different ways as defined and covered by the claims. Inthis description, reference is made to the drawings wherein like partsare designated with like numerals throughout.

FIG. 1 is a block diagram illustrating one embodiment of a DAT system100. The development and testing (“DAT”) system 100 allows developers tohave automatic and seamless access to their defined communicationinterfaces. In addition, the DAT system 100 enables threads to run ondistributed platforms, and allows any programming language seamlessaccess to the interfaces.

The DAT system 100 comprises an embedded computer 104 that is in datacommunication with a host computer 108. The embedded computer 104executes an embedded computer communication module 112 that is used toroute communications to threads 114 executing on the embedded computer104. The host computer 108 executes a host computer communication module116 that is used to route messages to threads 120 executing on the hostcomputer 108. The embedded computer communication module 112 and thehost computer communication module 116 are able to route to each othermessages and/or other communications sent via other interfacesoriginating from one platform that are destined for transmission to theother platform. In one embodiment of the invention, all communicationsfrom one platform to the other platform are transmitted via the embeddedcomputer communication module 112 and the host computer communicationmodule 116.

The embedded computer 104 can reside on a telephone, a card on aperipheral device, an automobile, a refrigerator, or any otherelectronic device. The host computer 108 can include any computingdevice that includes a display and an input device, e.g., mouse,keyboard.

The host computer 116 also comprises a communication database 124 thatautomatically compiles the embedded and host's interface definitionfiles to capture the “characteristics” of a communication interface.

The DAT system 100 provides a standardized API for messaging andtracing, contains a protocol suite used to implement a seamlessmessaging and tracing environment, and implements the communication linkbetween the two platforms. In one embodiment of the invention, the APIthat is provided by the DAT system 100 includes interfaces for thefollowing: (i) registering a message; (ii) reading a message; (iii)sending command data; (iv) sending response data; (v) broadcasting amessage; (vi) subscribing to a message; (vii) returning the list ofmessages stored in the communication database; (viii) returning themessage format of a specific message; and (ix) returning the name and/oridentifier of a specific message. Further exemplary API of the DATsystem 100 are described below.

A studio module 128 provides a graphical user interface and testingenvironment for testing the communication interfaces that are identifiedby the communication database 124. The DAT system 100 provides completevisibility and control of all the messages and remote function callsdefined by an embedded software application. As an example, using thestudio module 128, a developer can scan the entire list of messagesand/or remote function calls within the database and display them on ascreen. Once a specific message or remote function call is selected, thecommunication database 124 can be queried to return the element typesand names associated with the message.

Upon execution, each of the threads in the embedded computer 104 and thehost computer 108 register with the DAT system 100. Registration enablesthe DAT system 100 to dynamically route messages without having to“hardcode” a routing table. Threads at anytime can call a specificapplication programming interface “API” that is offered by the DATsystem 100 to inform the DAT system 100 that the requesting thread“owns” a selected message. Owns, in this context, means that thespecific thread receives the message anytime another thread and orapplication sends it. When a request to send a message is issued, theDAT system 100 determines whether the owning thread is local or on theother platform. If the platform is local, the message is directly routedto the owning thread. If the platform is remote, the message is directlyrouted to the other platform. If the message originates at the embeddedcomputer 104, upon receipt, the host computer 108 formats the message tobe compatible with the machine characteristics of the host computer 108.If the message originates at the host computer 108, the host computer108 formats the messages to be compatible with the machinecharacteristics of the embedded computer 104.

The embedded computer communication module 112, the host computercommunication module 116, and the studio module 128 each comprisevarious sub-routines, procedures, definitional statements, and macros.The computer communication module 112, the host computer communicationmodule 116, and the studio module 128 may be written in any programminglanguage such as C, C++, BASIC, Java, Pascal, and Fortran and may be rununder the well-known operating system. C, C++, BASIC, Pascal, Java, andFortran are industry standard programming languages for which manycommercial compilers can be used to create executable code.

The embedded computer 104 may execute under the control of anyoff-the-shelf or proprietary real-time operating system such as:VxWorks, Nucleus, ThreadX, Windows CE, RTXC, and Embedded Linux.

The host computer 108 may execute under the control of any off-the-shelfor proprietary operating system, such as: UNIX, LINUX, Disk OperatingSystem (DOS), OS/2, PalmOS, VxWorks, Windows 3.X, Windows 95, Windows98, Windows NT, Windows CE, and Windows XP. Each of the threads onembedded computer 104 and the host computer 108 can communicationrespectively with the embedded computer communication module 112 and thehost computer communication module 116 via a predefined applicationprogramming interface API. Set forth below are described certainroutines provided by the APT. It is to be appreciated that otherroutines may also be provided.

Application Programming Interfaces Owner Methods Methods BroadcastBroadcasts a response to all subscribed Users. (Broadcast message typeonly) Read Command Reads the Command sent by a User (One-way & Two- waymessage types only) Register Registers ownership of the serviceassociated with the message (One-way & Two-way message types only) SendResponse Sends the response. (Two-way message type only) Un-registerUn-registers ownership of the service. (One-way & Two-way message typesonly) User Methods Methods Read Response Reads the Response sent fromthe owner. (Two-way and Broadcast message types only) Send and ReadCombines the Send Command and Read Response methods (Two-way messagetype only) Send Command Sends the Command to the registered Owner(One-way and Two-way message types only) Subscribe Subscribes to theservice associated with the Message. Once subscribed the Message objectwill receive all broadcasts sent by any owner of the service. (Broadcastmessage type only) Un-subscribe Un-subscribes to the service. Spy APIMethods Read Command Reads (spies on) a copy of a command sent from aUser to the Register Owner Read Response Reads (spies on) a copy of aResponse sent from the Owner to the User Register Register as a spy ofthe interface to thereafter receive copies of all Commands and Responsessent by Owners and Users of the Service. Un-register Un-register theobject as a spy <Dataset methods> Defined below Owner Functions APIMethods Register Registers ownership of the service associated with thefunction Read Parameter List Reads the Parameter List sent by the CallerReturn Sends the Return Value to the Caller (User). Un-registerUn-registers ownership of the function. <Dataset methods> Defined belowUser Function API Methods Call Calls the remote function with theObject's Parameter List Read Return Value Reads the Return Valuereturned by the Owner. Spy Function API Methods Read Parameter ListReads (spies on) a copy of the Parameter List sent by the Caller ReadResponse Reads (spies on) a copy of the Response sent from the Owner tothe User Register Register the Object as spy of the interface tothereafter receive copies of all Calls and Returns made between usersand owners of the function. Un-register Un-register the object as a spy.<Dataset methods> Defined below Datasets Methods Clear All DatasetsClears/Deletes all datasets associated with either the Command orResponse (Messages), or Input or Output (Functions) Delete DatasetsDeletes a specified number of datasets Insert Datasets Inserts aspecified number of datasets. Load Datasets Loads datasets from thedatabase and associates them with the interface object. Store DatasetsStores the datasets currently associated with the interface object intothe database. Miscellaneous API Methods Pointer Setup Specify theattributes of a the pointer, e.g., IN, IN/OUT, OUT, pooled, private.Pointer Attach Invoked each time a pointer address or size is modified

FIG. 2 presents a functional block diagram of the communication database124. The communication database 124 includes a compiler 200 and anaccess engine 204. The communication database 124 parses standardinterface definition files, such as in C, C++, or other programminglanguage, and automatically extracts out the interface and tracinginformation. The interface definition files contain the formats of theinterfaces that are used for thread communication and software tracing.In one embodiment of the invention, a programmer can define thesecharacteristics in the interface definition file via the use of compilerpragmas.

The information from the interface definition files is organized andstored in the communication database 124 such that it that can beaccessed by other desktop applications via the host computercommunication module 116. An exemplary process of building thecommunication database 124 is described below with respect to FIG. 9.

In one embodiment of the invention, the DAT system 100 provides seamlessand automatic ability for an application on the host computer 108 tomake a remote function call to a routine that is on the embeddedcomputer 104 and vice-versa, without requiring modification of theapplication other than to link the libraries and header files of the DATsystem 100. An exemplary process of automatically generating code insupport of a remote function call is described below with reference toFIG. 31.

FIG. 3 is a block diagram illustrating another exemplary embodiment ofthe invention. The embodiment of the invention shown in FIG. 3 allowsscripting languages to seamlessly access threads that are executing onthe embedded computer 104 and the host computer 108.

With respect to the embodiment of the invention shown in FIG. 3, the DATsystem 100 also comprises a messaging automation component (“MAC”) 304and a script engine 312 for executing a script. In one embodiment of theinvention, the MAC 304 is a COM-compliant object that providesinterfaces for performing the following functions: designating ownershipof an interface, generating a data set, sending a field of information,sending a data set, receiving a message, and listing each of themessages that are managed by the DAT system 100. The script engine 312can be any proprietary or off-the-shelf engine that supports scriptinglanguages such as: JavaScript, Visual Basic, VBScript, Tcl, JScript,Python, etc.

Set forth below is a description of the various objects that areprovided by the MAC 304 for communication. In one embodiment of theinvention, there are 6 classes of interface objects: (i) owner messageobjects; (ii) user message objects; (iii) spy message objects; (iv)owner function objects; (v) user function objects; and (vi) spy functionobjects. It is to be appreciated that other type of objects may also beused.

The application programming interfaces of the MAC 304 are set forthbelow.

Owner Message Object Methods Broadcast Broadcasts a response to allsubscribed Users. (Broadcast message type only) Read Command Reads theCommand sent by a User (One-way & Two- way message types only) RegisterRegisters ownership of the service associated with the message (One-way& Two-way message types only) Send Response Sends the response. (Two-waymessage type only) Un-register Un-registers ownership of the service.(One-way & Two-way message types only) <Dataset methods> Defined belowProperties Name Name of the Interface SUID STRIDE Unique Identifier forthe Interface Command Payload Command payload of the Message Object.Response Payload Response pay load of the Message Object. Out PointerData Out pointer data - defined as part of the Command payload,populated as apart of the Response. <Dataset properties> Defined belowUser Message Object Methods Read Response Reads the Response sent fromthe owner. (Two-way and Broadcast message types only) Send and ReadCombines the Send Command and Read Response methods (Two-way messagetype only) Send Command Sends the Command to the registered Owner(One-way and Two-way message types only) Subscribe Subscribes to theservice associated with the Message. Once subscribed the Message objectwill receive all broadcasts sent by any owner of the service. (Broadcastmessage type only) Un-subscribe Un-subscribes to the service. <Datasetmethods> Defined below Properties Name Name of the Interface SUID STRIDEUnique Identifier for the Interface Command Payload Command payload ofthe Message Object. Response Payload Response payload of the MessageObject. Out Pointer Data Out pointer data - defined as part of theCommand payload, populated as apart of the Response. <Datasetproperties> Defined below Spy Message Object Methods Read Command Reads(spies on) a copy of a command sent from a User to the Register OwnerRead Response Reads (spies on) a copy of a Response sent from the Ownerto the User Register Register as a spy of the interface to thereafterreceive copies of all Commands and Responses sent by Owners and Users ofthe Service. Un-register Un-register the object as a spy <Datasetmethods> Defined below Properties Name Name of the Interface SUID STRIDEUnique Identifier for the Interface Command Payload Command payload ofthe Message Object. Response Payload Response payload of the MessageObject. Out Pointer Data Out pointer data - defined as part of theCommand payload, populated as apart of the Response. <Datasetproperties> Defined below Owner Function Object Methods RegisterRegisters ownership of the service associated with the function ReadParameter List Reads the Parameter List sent by the Caller Return Sendsthe Return Value to the Caller (User). Un-register Un-registersownership of the function. <Dataset methods> Defined below PropertiesName Name of the Interface SUID STRIDE Unique Identifier for theInterface Parameter List List of parameters for the Function Object.Return Value Return value for the Function Object. Out Pointer Data Outpointer data - defined as part of the Parameter List, populated as apartof the Output. <Dataset properties> Defined below User Function ObjectMethods Call Calls the remote function with the Object's Parameter ListRead Return Value Reads the Return Value returned by the Owner. <Datasetmethods> Defined below Properties Name Name of the Interface SUID STRIDEUnique Identifier for the Interface Parameter List List of parametersfor the Function Object. Return Value Return value for the FunctionObject. Out Pointer Data Out pointer data - defined as part of theParameter List, populated as apart of the Output. <Dataset properties>Defined below Spy Function Object Methods Read Parameter List Reads(spies on) a copy of the Parameter List sent by the Caller Read ResponseReads (spies on) a copy of the Response sent from the Owner to the UserRegister Register the Object as spy of the interface to thereafterreceive copies of all Calls and Returns made between users and owners ofthe function. Un-register Un-register the object as a spy. <Datasetmethods> Defined below Properties Name Name of the Interface SUID STRIDEUnique Identifier for the Interface Parameter List List of parametersfor the Function Object. Return Value Return value for the FunctionObject. Out Pointer Data Out pointer data - defined as part of theParameter List, populated as apart of the Output. <Dataset properties>Defined below Datasets Methods Clear All Datasets Clears/Deletes alldatasets associated with either the Command or Response (MessageObjects), or Input or Output (Function Objects) Delete Datasets Deletesa specified number of datasets Insert Datasets Inserts a specifiednumber of datasets. Load Datasets Loads datasets from the database andassociates them with the interface object. Store Datasets Stores thedatasets currently associated with the interface object into thedatabase.

In one embodiment, for message objects, datasets are sets of dataassociated with either the command (command payload) or response(response payload and out pointer data). One-way messages have commanddatasets, broadcast messages have response datasets, and two-waymessages have both. For function objects, datasets are associated witheither the input (parameter list) and/or the output (return value andout pointer data).

Scripting languages allow developers to customize, automate testing, andadd macro capabilities. Scripting languages, in general, are easy to usefor this type of functionality. Scripting languages also contain much ofthe same capability found in compiled languages such as loops,conditional statements, etc. A script program is text written in ascript language that is executed by a script engine. The messagingautomation component 304 provides a script program seamless and instantaccess to the communication interfaces of each of the threads in theembedded computer 104 and the host computer 108. Using the messagingautomation component 304, fields in a message or parameters in a remotefunction call can be set, read, tested against, or used in expressions.Via the messaging automation component 304, the scripting program canalso transmit and receive communications seamlessly with softwarerunning on either an embedded computer 104 or the host computer 108.Furthermore, establishing such communication does not require codechanges of the threads executing on either the embedded computer 104and/or the host computer 108.

In one embodiment of the invention, the script program is launched viaan interface that is provided by the studio module 128. In anotherembodiment of the invention, the script program does not have to belaunched by the studio module 128, but instead, can be launched andcommunicate directly with the host computer communication module 116.

FIGS. 4A and 4B illustrate exemplary scripts that can execute in thescript engine 312 to communicate with one of the threads 114 that areexecuting on the embedded computer 104 and/or the host computer 108.Code block 404 illustrates exemplary code that may be used to send a twoway message. On line 3 of code block 404, the script sets an object“msg” equal to one of the messages that is maintained in thecommunication database 124. At line 6, the script sets a field in apayload that is associated with the message. As is known in the art, apayload is structured data. At line 9, the script sends a commandmessage and waits for a response. At line 11, the script retrieves theresponse data. Code block 408 illustrates exemplary code that may beused to subscribe to a broadcast. Code block 412 illustrates exemplarycode that may be used to invoke a function. Code block 416 illustratesexemplary code that may be used to register ownership of a function.

FIG. 5 is a block diagram illustrating another embodiment of theinvention. A COM composer 504 automatically builds a generated component508 that serves as an interface between a COM-compliant application 512and the host computer communication module 116. COM is a Microsofttechnology that enables different applications to communicate with eachother using a known interface, independent of the languages that theapplications were developed in. For compatibility purposes, COMspecifies the particular format and protocol of the interfaces.

The generated component 508 provides the COM-compliant application 512seamless and instant access to the communication interfaces of anembedded application through predefined API. Using the generatedcomponent 508, the COM-compliant application 512 seamlessly communicateswith threads executing on the embedded computer and the host computer108. The host computer communication platform 116 automatically formatscommunication in a form suitable for its destination. An exemplaryprocess of formatting a communication is described below with referenceto FIG. 11.

Set forth below is a description of the application programminginterfaces that are provided by the generated component 508.

Owner Message Object Methods Broadcast Broadcasts a response to allsubscribed Users. (Broadcast message type only) Read Command Reads theCommand sent by a User (One-way & Two- way message types only) RegisterRegisters ownership of the service associated with the message (One-way& Two-way message types only) Send Response Sends the response. (Two-waymessage type only) Un-register Un-registers ownership of the service.(One-way & Two-way message types only) <Dataset methods> Defined belowProperties Name Name of the Interface SUID STRIDE Unique Identifier forthe Interface Command Payload Command payload of the Message Object.Response Payload Response payload of the Message Object. Out PointerData Out pointer data - defined as part of the Command payload,populated as apart of the Response. <Dataset properties> Defined belowUser Message Object Methods Read Response Reads the Response sent fromthe owner. (Two-way and Broadcast message types only) Send and ReadCombines the Send Command and Read Response methods (Two-way messagetype only) Send Command Sends the Command to the registered Owner(One-way and Two-way message types only) Subscribe Subscribes to theservice associated with the Message. Once subscribed the Message objectwill receive all broadcasts sent by any owner of the service. (Broadcastmessage type only) Un-subscribe Un-subscribes to the service. <Datasetmethods> Defined below Properties Name Name of the Interface SUID STRIDEUnique Identifier for the Interface Command Payload Command payload ofthe Message Object. Response Payload Response payload of the MessageObject. Out Pointer Data Out pointer data - defined as part of theCommand payload, populated as apart of the Response. <Datasetproperties> Defined below Spy Message Object Methods Read Command Reads(spies on) a copy of a command sent from a User to the Register OwnerRead Response Reads (spies on) a copy of a Response sent from the Ownerto the User Register Register as a spy of the interface to thereafterreceive copies of all Commands and Responses sent by Owners and Users ofthe Service. Un-register Un-register the object as a spy. <Datasetmethods> Defined below Properties Name Name of the Interface SUID STRIDEUnique Identifier for the Interface Command Payload Command payload ofthe Message Object. Response Payload Response payload of the MessageObject. Out Pointer Data Out pointer data - defined as part of theCommand payload, populated as apart of the Response. <Datasetproperties> Defined below Owner Function Object Methods RegisterRegisters ownership of the service associated with the function ReadParameter List Reads the Parameter List sent by the Caller Return Sendsthe Return Value to the Caller (User). Un-register Un-registersownership of the function. <Dataset methods> Defined below PropertiesName Name of the Interface SUID STRIDE Unique Identifier for theInterface Parameter List List of parameters for the Function Object.Return Value Return value for the Function Object. Out Pointer Data Outpointer data - defined as part of the Parameter List, populated as apartof the Output. <Dataset properties> Defined below User Function ObjectMethods Call Calls the remote function with the Object's Parameter ListRead Return Value Reads the Return Value returned by the Owner. <Datasetmethods> Defined below Properties Name Name of the Interface SUID STRIDEUnique Identifier for the Interface Parameter List List of parametersfor the Function Object. Return Value Return value for the FunctionObject. Out Pointer Data Out pointer data - defined as part of theParameter List, populated as apart of the Output. <Dataset properties>Defined below Spy Function Object Methods Read Parameter List Reads(spies on) a copy of the Parameter List sent by the Caller Read ResponseReads (spies on) a copy of the Response sent from the Owner to the UserRegister Register the Object as spy of the interface to thereafterreceive copies of all Calls and Returns made between users and owners ofthe function. Un-register Un-register the object as a spy. <Datasetmethods> Defined below Properties Name Name of the Interface SUID STRIDEUnique Identifier for the Interface Parameter List List of parametersfor the Function Object. Return Value Return value for the FunctionObject. Out Pointer Data Out pointer data - defined as part of theParameter List, populated as apart of the Output. <Dataset properties>Defined below Datasets Methods Clear All Datasets Clears/Deletes alldatasets associated with either the Command or Response (MessageObjects), or Input or Output (Function Objects) Delete Datasets Deletesa specified number of datasets. Insert Datasets Inserts a specifiednumber of datasets. Load Datasets Loads datasets from the database andassociates them with the interface object. Store Datasets Stores thedatasets currently associated with the interface object into thedatabase.

It is noted, that in one embodiment, the MAC 304, the studio module 128,the generated component 508, can be utilized together to provide acommunication system for various types of applications. For example,using the application programming interface of the MAC 304, a scriptingprogram in a first language can communicate with a scripting program inthe same or a second language, a COM-compliant application 512 via thegenerated component 508, a thread executing on the embedded computer104, a thread executing on the host computer 108, and the studio module128.

Furthermore, for example, using the application programming interface ofthe generated component 508, a COM-compliant application can communicatewith a scripting program via the MAC 304, another COM-compliantapplication, a thread executing on the embedded computer 104, a threadexecuting on the host computer 108, and the studio module 128.

Furthermore, for example, using the studio 128, a user can send andreceive messages to and from the COM-compliant application 512, ascripting program, a thread executing on the host computer 108, a threadexecuting on the embedded computer 104.

FIG. 6 is a representational block diagram illustrating one embodimentof the communication database 124. Depending on the embodiment,additional types of information may be added to the database and/orcertain types of information may be omitted.

The communication database 124 includes a platform-specificconfiguration section 604. The platform-specific configuration section604 contains embedded computer machine characteristics and host computermachine characteristics. The characteristics can include items, such as:an indication of whether the platform is big or little Endian,enumeration sizes, pointer sizes, structure alignment boundaries, etc.It is noted that in one embodiment of the invention, the embeddedcomputer machine characteristics and the host computer machinecharacteristics are stored in a location other than the communicationdatabase 124, such as the host computer communication module 116 or theembedded computer 104.

The communication database 124 also includes a messages section 608 anda prototypes section 610. The messages section 608 and the prototypessection 610 respectively describe the characteristics of each of themessages and remote function calls on the embedded computer 104 and thehost computer 108. The characteristics can include: (i) the unique nameand or identifier of the message; (ii) the total size of the message;(iii) the type of the communication, e.g., one-way message, two-waymessage, broadcast message, remote function call; and (iv) the types ofdata are passed as part of the communication. A one way message is sentfrom a “user” of the communication to the “owner” of the communication.A thread can request ownership of a message via a registration routinethat is provided via an application programming interface of the hostcomputer communication module 116. A two way message comprises a“command” that is sent from the user to the owner and a “response” thatis sent from the owner to the user. A broadcast message is sent to allthreads that have registered to receive the broadcast.

The communication database 124 also includes a trace points section 612for maintaining trace points. The communication database 124 alsoincludes a description of the data types that are supported by themessages identified in the messaging section 608 and the functionslisted in the prototypes section 610.

The data types section 616 includes: (i) a description of the data typesin the data structures that are part of a message or remote functioncall, e.g., integer, character, Boolean, floating-point, arrays, etc;(ii) the field name of each of the elements in each of the messages;(iii) and a description of characteristics of embedded pointers that maybe part of the message.

FIG. 7 is a block diagram illustrating an exemplary component hierarchyof the generated component 508. The COM-compliant object 512 initiallyaccesses the generated component 508 via a root object 704. Via the rootobject 704, the COM-compliant object 512 can send commands and receiveresponses from particular messages and remote function calls that aredefined in the communication database 124. For example, as is shown inFIG. 7, the COM-compliant object has access to an object 708 that isassociated with “MESSAGE 1” and an object 712 that is associated with“MESSAGE 2.” Using predefined interfaces associated with these messageobjects, the COM-compliant object 512 can send and receive payloads withthreads that are executing on the embedded computer 104.

FIG. 8 is a flowchart illustrating a process of modifying source code tocommunicate with the DAT system 100. Depending on the embodiment,additional steps may be added, others removed, and the ordering of thesteps rearranged. Starting at a step 804, a programmer adds API calls toinvoke a registration method that is provided by the DAT system 100. Inone embodiment of the invention, a registering thread provides a uniquethread identification code.

Next, at a step 808, the programmer adds API calls to invoke a readmethod that is provided by the DAT system 100. Continuing to a step 812,the programmer adds, where applicable, API calls to invoke a send methodthat is provided by the DAT system 100.

Continuing to a state 816, the programmer adds API calls to “subscribe”to a message. Subscribing to a message allows a subscriber to bind to aspecific message and thereafter receive all broadcast transmissions.Other messaging APIs may be provided by the DAT system 100 such as forthe following: sending a command; sending a response; broadcasting amessage; and defining the data (content) and meta-data (characteristics)of the payload of a message.

FIG. 9 is a block diagram illustrating an exemplary process of buildingthe communication database 124. Depending on the embodiment, additionalsteps may be added, others removed, and the ordering of the stepsrearranged. In one embodiment of the invention, the process shown inFIG. 9 is performed in response to a user request.

Starting at a state 904, the studio module 128 reads and extractsinformation from each of a plurality of interface definition files thatare provided by the user. Next, at a step 908, the studio module 128extracts the communication interfaces from each of the interfacedefinition files. Information that is extracted can include: (i) thetype of the communication, e.g., one-way, two-way, broadcast, remotefunction call; (ii) the types of data are passed as part of thecommunication; (iii) a description of the data types in the datastructures that are part of a message or remote function call, e.g.,integer, character, Boolean; (iv) a description of characteristics ofembedded pointers that may be part of the message, e.g., whether thememory is “pooled” or “private”, a method of transmitting the memorythat is associated with the communication interface, and pointer datathat is associated with the communication interface.

Next at a step 916, the studio module 128 stores the embedded computermachine characteristics. The embedded computer machine characteristicscan be provided by user entry, automatic diagnosis of the embeddedcomputer 104, or automatically provided by the embedded computer 104.Examples of the embedded computer machine characteristics are describedabove with respect to FIG. 6. In one embodiment, it is assumed thatthese characteristics are fixed, i.e., exactly the same on eachconnection.

Proceeding to a step 920, the studio module 128 stores the host computermachine characteristics. The host computer machine characteristics canbe provided by user entry or automatic diagnosis of the host computer108. Examples of the host computer machine characteristics are describedabove with respect to FIG. 6.

FIG. 10 is a flowchart illustrating a process of using the DAT system100. Depending on the embodiment, additional steps may be added, othersremoved, and the ordering of the steps rearranged. Starting at a step1004, the DAT system 100 receives registration information from eachthread. Next, at a step 1008, the DAT system receives a payload for aparticular message.

Continuing to a step 1012, the DAT system 100 formats the payload fortransmission to its destination thread. It is noted that if thedestination thread is local to the transmitting thread, then formattingmay be unnecessary. An exemplary process of formatting data fortransmission to a remote platform is described below with reference toFIG. 11. Moving to a step 1016, the DAT system 100 transmits theformatted payload to the destination thread.

FIG. 11 is a flowchart illustrating a process of formatting data for useon an different platform. Depending on the embodiment, additional stepsmay be added, others removed, and the ordering of the steps rearranged.In one embodiment of the invention, the process that is performed byFIG. 11 is performed by the host computer communication module 116 ofthe DAT system 100. Furthermore, FIG. 11 is directed to a process offormatting a payload for transmission from one platform, e.g., the hostcomputer 108 to another, e.g., the embedded computer 104.

The use of the process shown in FIG. 11 provides interoperabilitybetween applications communicating with each other on distributedheterogeneous computing platforms. In one embodiment of the invention,to reduce processing and memory requirements on embedded devices, theDAT system 100 performs all data formatting on the host computer 108.

The host computer 108 uses the platform characteristics of the embeddedcomputer 104 and the host computer 108 and the individual interfacedefinition information (“the communication interface information”) toproperly map messages when two applications on the different computersare communicating. In one embodiment, the embedded computer 104 alwayssends and receives messages in its native form, i.e., the form in whichthe message is stored in its memory. The host computer 108 maps thesemessages into its form when receiving them, and transforms the messagesinto the embedded computer 104 platform's native form when transmittingthe messages to the embedded computer 104.

Starting at a decision state 1104, the host computer communicationmodule 116 determines whether the destination thread is local or remote.If the thread is local, the process proceeds to a step 1108 and thepayload is queued for transmission to the destination thread. If thetransmission is local, no further modification of the payload isnecessary.

Referring again to the decision step 1104, if the destination thread isnot local, the process proceeds to a step 1112, wherein the hostcomputer communication module 116 copies data in payload and datareferenced by pointers into a message for transmission to the embeddedcomputer 104. An exemplary process of managing pointer data is describedin further detail below with reference to FIGS. 12A, 12B, 12C, and 12D.

Continuing to a step 1116, the host computer communication module 116formats, if necessary, the byte order of the elements in data in thepayload. For example, if the host computer 108 is Big Endian, and theembedded computer 104 is Little Endian, or vice-versa, the host computercommunication module 116 reverses the order of the bits in the data.

Proceeding to a step 1124, the host computer communication module 116formats the size of the data types in the payload. For example, if theembedded computer 104 uses a certain bit-length for certain data typesand the host computer uses a different bit-length, the host computercommunication module 116 adjusts the size of the data for transmissionto the other platform. Moving to a step 1128, the host computercommunication module 116 adjusts alignment of the data structuresaccording to any requirement of the receiving platform.

FIGS. 12A-12D each illustrate an exemplary method of managing pointersin a payload that are passed from one platform to another. FIG. 12A isdirected to a process of receiving a payload from a thread on theembedded computer 104 in connection with a “command” message. In oneembodiment, FIG. 12A is performed with respect to each of the pointersin the payload. Depending on the embodiment, additional steps may beadded, others removed, and the ordering of the steps rearranged. In oneembodiment of the invention, the method shown in FIG. 12 is performed bythe host computer communication module 116. It is noted that a similarprocess as shown in FIG. 12 is performed on the embedded computercommunication module 112 when the embedded computer communication module112 receives a command message. However, in one embodiment, for such aprocess the embedded computer communication module 112 does not performany of inter-platform formatting of the received data as such formattingis performed by the host computer communication module 116.

Before starting at a state 1204, a thread on the embedded computer 104has invoked a send command that is part of the application programminginterface of the embedded computer communication module 112. Inresponse, the embedded computer communication module 112 has built andthen transmitted an inter-platform message to the host computercommunication module 116. The inter-platform message includes thepayload that was identified as part of the send command and, ifapplicable, the data that is referenced by the pointers in the payload.

Starting at a step 1204, the host computer communication module 116 getsthe embedded pointer attributes of a selected pointer in the payload ofthe transmitted communication. In one embodiment of the invention, theattribute information is stored in the transmitted communication. Afirst attribute of each pointer is whether the pointer is classified as“IN”, “OUT”, or “IN/OUT”. The “IN” attribute designates that the datareferenced by the pointer is passed from the sender of the command tothe owner of the message but no data is to be returned by the owner ofthe message. The “OUT” attributes designates that the sender of thecommand will not transmit any data that is referenced by the pointer butdata will be returned by the owner and stored in the address referencedby the pointer. The “IN/OUT” attribute indicates that the data that isreferenced by the pointer will be sent from the sender of the commandand that the owner of the message will return data that is stored in thememory referenced by the pointer.

A second attribute of each pointer is whether the pointer is “private”or “pooled.” Management (freeing of the memory when not in use) of“private” memory is handled by the DAT system 100. Management of“pooled” memory is handled by the user and/or the owner of a message.

Continuing to a step 1210, the host computer communication module 116creates a local buffer to hold the pointer data. Continuing to adecision step 1212, the host computer communication module 116determines whether the pointer attribute is either “IN” or “IN/OUT”. Ifthe pointer attribute is “IN” or “IN/OUT”, the process proceeds to astep 1214. Continuing to a step 1214, the host computer communicationmodule 116 copies the pointer data that was transmitted from theembedded computer 104 into the local buffer. At this step, the hostcomputer communication module 116 formats the pointer data in accordancewith the process described above with reference to steps 1116, 1124, and1128.

Next, at a step 1218, the host computer communication module 116 copiesthe address of the buffer into the payload. Proceeding to a decisionstep 1220, the host computer communication module 116 determines whetherthe first attribute of the pointer is “IN”. If the first attribute ofthe pointer is “IN” the process proceeds to a decision step 1222. At thedecision step 1222, the host computer communication module 116determines whether the second attribute of the pointer is “private”. Ifthe second attribute of the pointer is private, the process proceeds toa step 1228. Otherwise if the second attribute of the pointer is notprivate, i.e., pooled, the process ends.

Referring again to the decision step 1212, if the first attribute is not“IN” or “IN/OUT”, the attribute is the “OUT” and the process proceeds toa step 1216. At the step 1216, the host computer communication module116 copies the address of the local buffer into the payload. From step1216, or from decision step 1220 (if the first attribute is “IN/OUT”),the process proceeds to a step 1224. At this step, the host computercommunication module 116 waits for thread on the host computer 108 toinvoke a response command that is provided by the applicationprogramming interface of the DAT system 100. Upon receiving theresponse, the process proceeds to a step 1226. At this step, theresponse data is formatted for transmission to the embedded computer104.

From either step 1226 or from the decision step 1222 (if the secondattribute of the pointer is “private”), the process proceeds to a step1228 wherein the host computer communication module 116 waits for athread on the host computer 104 to invoke a read complete command thatis in the application programming interface of the host computercommunication module 116. Upon receipt of the read complete command, theprocess proceeds to a step 1230 wherein the host computer communicationmodule frees the memory.

FIG. 12B is directed to a process of managing pointers in a payload in acommand message that is sent from a thread on the host computer 108 to athread on embedded computer 104. FIG. 12B illustrates in further detailthe steps that occur in step 111 of FIG. 11. In one embodiment. FIG. 12Bis performed with respect to each of the pointers in the payload.Depending on the embodiment, additional steps may be added, othersremoved, and the ordering of the steps rearranged. A similar process isperformed by the embedded computer when transmitting a command messagefrom a thread on the embedded computer 104 to the host computer 108.However, in this process, the embedded computer communication module 112does not perform any formatting of the transmitted payload since theformatting is performed by the host computer communication module 116upon receipt of the payload.

Starting at a step 1230, the host computer communication module 116creates a buffer to hold an inter-platform message for transmission tothe embedded computer 104. Also, at this step, the host computercommunication module 116 creates a header in the inter-platform messagefor the embedded pointer. Furthermore, at this step, the host computercommunication module 116 stores the pointer attributes of the pointer inthe inter-platform message.

Continuing to a decision step 1232, the host computer communicationmodule 116 determines whether the pointer attribute of the pointer is“OUT”. If the attributes of a selected pointer is “OUT”, the processends. However, if the pointer attribute is not “OUT”, i.e., it is “IN”or “IN/OUT”, the process proceeds to step 1244. At the step 1244, hostcomputer communication module 116 copies the data referenced by thepointer into the header. Furthermore, the host computer communicationmodule 116 formats the data for use by a thread on the embedded computer108. For example, the host computer communication module performs thesteps described above with respect to steps 1116, 1124, and 1128.

Next, at a decision step 1236, the host computer communication module116 determines whether the pointer attributes is “IN.” If the pointerattribute is “IN”, the process proceeds to a step 1240. At this step,the host computer communication module 116 frees the memory, ifwarranted, i.e., the attributes of the pointer designate “pool”.However, if the pointer attribute is not “IN”, the proceeds ends.

FIG. 12C is directed to a process of receiving a response message fromthe embedded computer communication module 112. FIG. 12C illustrates infurther detail the steps that occur in step 111 of FIG. 11. In oneembodiment, FIG. 12C is performed with respect to each of the pointersin the payload. Depending on the embodiment, additional steps may beadded, others removed, and the ordering of the steps rearranged. Asimilar process is performed by the embedded computer 104 whentransmitting a command message from a thread on the embedded computer104 to the host computer 108. However, in this process, the embeddedcomputer communication module 112 does not perform any formatting of thetransmitted payload since the formatting is performed by the hostcomputer communication module 116 upon receipt of the payload.

Before starting at a state 1250, a thread on the embedded computer 104has invoked a send response command that is part of the applicationprogramming interface of the embedded computer communication module 112.In response, the embedded computer communication module 112 has builtand then transmitted an inter-platform message to the host computercommunication module 116. The inter-platform message includes thepayload that was identified as part of the send response and, ifapplicable, the data that is referenced by the pointers in the payload.

Starting at a decision step 1250, the host computer communication module116 determines whether the pointer attributes of the pointer in theinter-platform message designate the attribute “IN”. If the pointerattributes designate the attribute “IN”, the process proceeds to a step1252, and the host computer communication module 116 formats thereceived data for use with the host computer 108. For example, in oneembodiment, the host computer communication module 116 performs thesteps described above with respect to steps 1116, 1124, and 1128.

However, if the pointer attributes do not designate “IN”, i.e., thepointer attributes designate “IN/OUT” or “OUT”, the process proceeds toa step 1254. At the step 1254, the host computer communication module116 creates a local buffer to store the pointer data that wastransmitted by the embedded computer 104. Continuing to a step 1256, thehost computer communication module 116 copies the pointer data from theinter-platform communication into the local buffer. Next, at step 1258,the host computer communication module 116 copies the address of thebuffer into the received payload.

Proceeding to a decision step 1260, the host computer communicationmodule 116 determines whether it should free the pointer. In oneembodiment of the invention, this is determined by reading the pointerattributes. If the pointer attributes designate “private” the hostcomputer communication module 116 decides to free the memory. However,if the pointer attributes designate “pooled” the host computercommunication module 116 allows the user to free the memory.

If the host computer communication module 116 determines in step 1260 tofree the memory, the process proceeds to a step 1262, wherein the hostcomputer communication module 116 waits for a thread on the hostcomputer 108 to invoke the read complete command. Continuing to a step1264, the host computer communication module 116 frees the local buffer.From either decision step 160 (if the host computer communication module116 does not free the pointer) or the step 1264 the process ends.

FIG. 12D is directed to an exemplary process of managing pointers in apayload in a response message that is sent from a thread on the hostcomputer 108 to a thread on embedded computer 104. FIG. 12D illustratesin further detail the steps that occur in step 1112 of FIG. 11. In oneembodiment, FIG. 12D is performed with respect to each of the pointersin the payload. Depending on the embodiment, additional steps may beadded, others removed, and the ordering of the steps rearranged. Asimilar process is performed by the embedded computer 104 whentransmitting a response message from a thread on the embedded computer104 to the host computer. However, in this process, the embeddedcomputer communication module 112 does not perform any formatting of thetransmitted payload since the formatting is performed by the hostcomputer communication module 116 upon receipt of the payload.

Before starting, a thread on the embedded computer 104 has sent acommand message and a thread on the host computer 108 has responded byinvoking the send response routine of API of the DAT system 100.

Starting at a step 1265, the host computer communication module 116allocates space in an outgoing buffer (“a header”) to store the datathat is referenced by the pointer. The outgoing buffer is part of aninter-platform message that is sent from the host computer communicationmodule 116 to the embedded computer communication module 112. Proceedingto a decision step 1266, the host computer communication module 116determines whether the pointer attributes designate “IN”. If the pointerattributes do designate “IN”, i.e., they do not designate “OUT” or“IN/OUT”, the process proceeds to a decision step 1267. At the decisionstep 1267, the host computer communication module 116 determines whetherto free memory that is associated with the memory that was allocatedduring the corresponding send command. In one embodiment of theinvention, this is determined by reading the pointer attributes. If thepointer attributes designate “pool” the host computer communicationmodule 116 decides to free the memory. However, if the pointerattributes designate “private” the host computer communication module116 allows the user to own and eventually free the memory (via anroutine provided by the local operating system). If the host computercommunication module 116 determines it should free the memory, theprocess proceeds to a step 1268, and the host computer communicationmodule 116 frees the memory. From either step 1268 or decision step 1266(if the pointer attributes does not designate “IN”), the processproceeds to a step 1270 and the host computer communication module 116formats the data referenced by the pointer for transmission to theembedded computer. For example, in one embodiment, the host computercommunication module 116 performs the steps described above with respectto steps 1116, 1124, and 1128. As part of the formatting, the formatteddata is stored in the header (step 1265).

FIG. 13 is flowchart illustrating a process of using the DAT system 100from a script in the script engine 312. Depending on the embodiment,additional steps may be added, others removed, and the ordering of thesteps rearranged. Starting at a step 1304, the studio module 128 hasreceived a request from a user to load a script file and it does sohere. Next, at a step 1312, studio determines script type that isassociated with the script file. The script type can be determined indifferent ways, including examining the extension of the identifiedscript file or from the contents of the script itself. Exemplary typesof scripting languages include: JavaScript, Visual Basic, VBScript, Tcl,JScript, Python, etc.

Moving to a step 1316, the studio module 128 identifies thecorresponding script engine 312 that is associated with the script type.Continuing to a step 1320, the studio module 128 initializes the scriptengine 312.

Next, at a step 1324, the studio module 128 loads the messagingautomation component (“MAC”) 304. The process of loading the MAC 304 isdescribed below with reference to FIG. 14. Proceeding to a step 1328,the MAC 304 is “exposed” to the script engine 312. In one embodiment ofthe invention, exposing the MAC 304 includes providing the script engine312 a handle to the MAC 304. Next, at a step 1332, the script engine islaunched, allowing the script loaded in a step 1304 to access the API ofMAC 304. Moving to a step 1336, a script program can communicate withthreads 114 using the API of the MAC 304. An exemplary process of usingthe MAC 304 is described below with respect to FIG. 15.

FIG. 14 is a flowchart illustrating a process of loading the MAC 304.FIG. 14 illustrates in further detail the steps that occur in step 1324of FIG. 13. Starting at a step 1404, the studio module 128 calls theinitialization routine of the MAC 304 and passes as a parameter a handleto the communication database 124. Next, at a step 1408, the MAC 304generates a messaging automation component “MAC” database object. TheMAC database object contains certain of the information from thecommunication database 114. The MAC database is used by the scriptingprogram to access application programming interfaces of the MAC 304.

FIGS. 15-17 are flowcharts illustrating a process of communicating withthe MAC 308 using a scripting language. Depending on the embodiment,additional steps may be added, others removed, and the ordering of thesteps rearranged. FIG. 15 is a flowchart directed to a process ofregistering a particular message with the MAC 304. Starting at a step1504, a script that is executing in the scripting engine 312 invokes aregister method of the MAC 304. Proceeding to a step 1508, the MACobject calls the register API of the host computer communication module116.

FIG. 16A is a flowchart illustrating a process of sending a message viathe MAC 304. Starting at a step 1604, the script retrieves reference toa MAC database object. Next, at a step 1606, the script requests the MACdatabase object to provide a reference to a message object. The messageobject is used by the script program to communicate with a owner of acommunications or to receive communications from others. Using themessage object, a script can set fields of the message, send a message,receive a message, and perform other standard messaging functions.

Continuing to a step 1610, the MAC database object retrieves the messagedefinition information from the communication database 124. In oneembodiment of the invention, the message definition information isretrieved via the host computer communication module 116. In anotherembodiment of the invention, the message definition information isretrieved directly from the communication database 124. The messagedefinition information includes: (i) the type of the communication,e.g., one-way, two-way, broadcast, remote function call and (ii) thetypes of data that are passed as part of the communication. Next, at astep 1614, the MAC database object creates a MAC message object basedupon the prototype definition retrieved from the communication database124.

Proceeding to a step 1618, the MAC database object retrieves any datasets from the communication database that are stored with respect to therequested message object. Next, at a step 1622, the MAC database objectadds the data sets to the message object (created in step 1614).

Moving to a step 1624, the MAC database object returns a reference tothe message object to the script. Next, at a step 1628 the script canset the data fields of the message using reference to the messageobject. The script has access via the MAC database object to a pluralityof readable and writeable data sets. At this step, the script canidentify one of the data sets for subsequent usage. Continuing to a step1632, the script invokes a send method of the method object. Proceedingto a step 1636, the MAC database object sends a data set that isreferenced by the current index to the thread that owns the message.

Next, at a decision step 1640, the MAC database object determineswhether auto-increment is enabled. Auto-increment enables a script tosend different data sets with each send command. If auto-increment isenabled, the process proceeds to a step 1644, and the MAC databaseobject selects the next data set. Referring again to the decision step1640, if auto-increment is not enabled, the process ends.

FIG. 16B is a flowchart illustrating a process of invoking a functionvia the MAC 304. Starting at a step 1650, the script retrieves referenceto the MAC database object. Next, at a step 1654, the script requeststhe MAC database object to provide a reference to a remote function callobject. The remote function call object is used by the script program tocommunicate with the thread that handles the remote function call. Usingthe remote function call object, a script can set the parameters thatwill be passed upon invoking the remote function call.

Continuing to a step 1658, the MAC database object retrieves the remotefunction call prototype definition information from the communicationdatabase 124. In one embodiment of the invention, the prototypedefinition information is retrieved via the host computer communicationmodule 116. In another embodiment of the invention, the messagedefinition information is retrieved directly from the communicationdatabase 124.

Next, at a step 1662, the MAC database object creates a MAC remotefunction call object based upon the remote function call prototypedefinition retrieved from the communication database 124.

Proceeding to a step 1664, the MAC database object retrieves any datasets from the communication database that are stored with respect to therequested remote function call object. Next, at a step 1666, the MACdatabase object adds the data sets to the MAC remote function callobject.

Moving to a step 1668, the MAC database object returns a reference tothe remote function call object to the script. Next, at a step 1670, thescript can set the data fields (parameters) of the remote function callusing the remote function call object. The script has access via the MACdatabase object to a plurality of readable and writeable data sets. Atthis step, the script can identify one of the data sets for subsequentusage. Continuing to a step 1672, the script invokes a call method ofthe remote function call object. Proceeding to a step 1674, the MACdatabase object sends a data set that is referenced by the current indexto the thread that handles the remote function call.

Next, at a decision step 1676, the MAC database object determineswhether auto-increment is enabled. Auto-increment enables a script tosend different data sets with each send command. If auto-increment isenabled, the process proceeds to a step 1678, and the MAC databaseobject selects the next data set. Referring again to the decision step1676, if auto-increment is not enabled, the process ends.

FIG. 17A is a flowchart illustrating a process of a script receiving amessage via the MAC 304. Depending on the embodiment, additional stepsmay be added, others removed, and the ordering of the steps rearranged.

Starting at a step 1700, the script calls a read method of the MACdatabase object. Next, at a step 1704, the MAC database object calls aread API of the host computer communication module 116. Continuing to astep 1708, the host computer communication module 116 waits for amessage to be received. Proceeding to a step 1712, the MAC databaseobject receives the message and a message identifier from the hostcomputer communication module 116. Next, at a step 1720, the MACdatabase object returns a message object to the script, which can inturn access the contents of the requested message.

FIG. 17B is a flowchart illustrating a process of a script receiving acommunication via function call application programming interfaces thatare provided by the MAC 304. Depending on the embodiment, additionalsteps may be added, others removed, and the ordering of the stepsrearranged. Starting at a step 1750, the script calls a read method ofthe MAC database object. Next, at a step 1754, the MAC database objectcalls the read API of the host computer communication module 116.

Continuing to a step 1758, the MAC database object waits for a remotefunction call command message to be received. Next, at a step 1762, theMAC database object receives the remote function command message and thefunction identifier.

Proceeding to a step 1764, a remote function call object is returned tothe script program. Next, at a step 1766, the script program access theinput parameters of the remote function call object.

Moving to a step 1768, the MAC database object returns a reference tothe remote function call object to the script. Next, at a step 1770, thescript invokes a return method of the remote function call object.Continuing to a step 1772, the remote function call object calls thesend application programming interface of the host computercommunication module 116. Proceeding to a step 1774, the MAC databaseobject sends a data set that is referenced by the current index to thethread that handles the remote function call.

Next, at a decision step 1776, the MAC database object determineswhether auto-increment is enabled. Auto-increment enables a script tosend different data sets with each send command. If auto-increment isenabled, the process proceeds to a step 1778, and the MAC databaseobject selects the next data set. Referring again to the decision step1776, if auto-increment is not enabled, the process ends.

FIG. 18 is a flowchart illustrating a process of interfacing with theDAT system 100 from any COM-compliant language. Depending on theembodiment, additional steps may be added, others removed, and theordering of the steps rearranged. Starting at a step 1804, a user loads“launches” the COM composer tool 504 (FIG. 5). An exemplary process ofloading the COM composer tool is described below with reference to FIG.19.

Next, at a step 1808, the COM composer builds the generated component508 (FIG. 5). The generated component 508 is a COM object that isaccessible by other COM compliant programs. Using the generatedcomponent 508, a COM-compliant program can easily: test a interface,send a communication to a thread that is executing on the embeddedcomputer 104 or the host computer 108, receive a communication that issent from a thread this executing on the embedded computer or the hostcomputer 108, and other functions as described herein. The generatedcomponent 508 provides a plurality of predefined interfaces forperforming each of the foregoing functions. An exemplary process ofbuilding the generated component 508 is described below with referenceto FIG. 20.

Continuing to a step 1816, the generated component 508 is accessible viaany COM-compliant language. An exemplary process of using the generatedcomponent is described below with reference to FIG. 22.

FIG. 19 is a flowchart illustrating an exemplary process of launchingthe COM composer tool 504. FIG. 19 illustrates in further detail certainsteps that occur in step 1804 of FIG. 18. Depending on the embodiment,additional steps may be added, others removed, and the ordering of thesteps rearranged.

Starting at a step 1904, a user identifies a database. The DAT system100 can support multiple databases for multiple projects. Continuing toa step 1908, the user selects which messages or functions of theselected database are to be included in the generated COM object. In oneembodiment of the invention, the user selects the messages and/or remotefunction calls via a graphical user interface utility.

Proceeding to a step 1912, the user selects the compiler version. TheCOM composer 504 needs to know the version of the compiler that is beingused to build the generated component 508 to provide the proper controlfiles in the proper format. Moving to a step 1916, the COM composer 504requests the user to designate the type of build, e.g., release ordebug.

FIG. 20 is a flowchart illustrating an exemplary process of building thegenerated component 508. FIG. 20 illustrates in further detail certainsteps that occur in step 1808 of FIG. 18. Depending on the embodiment,additional steps may be added, others removed, and the ordering of thesteps rearranged.

Starting at a step 2004, the COM composer tool loads the data that wasidentified by the user (step 1904) into memory. Next, at a step 2008,the COM composer tool begins a process that is performed with respect tothe following: (i) all of the messages and/or remote function callsidentified by the user (step 1908), (ii) all of the payloads of theidentified messages and/or remote function calls, and (iii) the rootobject that is used to access all other objects in the generatedcomponent 508. In one embodiment, steps 2012, 2016, 2020, and 2024 areperformed for each of the foregoing objects.

At the step 2012, the COM composer 504 generates a software interfacefor each of the objects. An exemplary process of generating an interfaceis described below with reference to FIG. 21. Next, at a step 2016, thegenerated component generates a COM class definition for the object,otherwise known as a co-class. Proceeding to a step 2020, the COMcomposer generates a COM class implementation for each of the COMobjects. For further information regarding generating softwareinterfaces, COM class definitions, and a COM class implementations,please see the following references, which are each incorporated byreference in their entirety: DON BOX, ESSENTIAL COM (1998), and BRENTRECTOR, CHRIS SELLS & JIM SPRINGFIELD, ATL INTERNALS (1999).

Moving to a decision step 2024, the COM composer 504 determines whetherit has processed all of the messages/remote function calls, payloads,and the root object. If all of these items have not been processed, theprocess returns to the step 2012 (discussed above). However, if all ofthe items have been processed, the COM composer 504 proceeds to a step2028 and provides any compiler specific files that are needed, if any.

Next, at a step 2032, the COM composer 504 launches the selectedcompiler to build the generated component 508. In one embodiment of theinvention, the COM component is provided in a dynamic link library“.DLL”. Moving to a step 2036, the COM composer 504 registers thedynamic link library with a registry in the host computer 108.

FIG. 21 is a flowchart illustrating a process of generating aninterface. FIG. 21 illustrates in further detail the steps that occur instep 2012 of FIG. 20. Depending on the embodiment, additional steps maybe added, others removed, and the ordering of the steps rearranged.

Starting at a step 2104, the COM composer 504 generates methoddefinitions for “built-in” member functions. Next, at a step 2108, theCOM composer 504 generates accessor function for child objects 2108. Forexample, the children of the root object includes each of the messagesand/or remote function calls. Furthermore, for example, the children ofa message object and/or a remote function call object includes one ormore payloads that are associated with the object. Moving to a step2112, the COM composer 504 generates interface for setting and gettingproperties of objects.

FIG. 22 is a flowchart illustrating a process of using the generatedcomponent 508. FIG. 22 illustrates in further detail certain steps thatoccur in step 1816 of FIG. 18. Depending on the embodiment, additionalsteps may be added, others removed, and the ordering of the stepsrearranged.

Before starting at a step 2216, the user has opened a COM developmentenvironment and located the via the COM development environment thegenerated component 508.

Starting at the step 2216, the user creates a reference to the generatedcomponent 508. Next, at a step 2220, the user creates an instance of theroot object. Moving to a step 2224, the user can use the root objectaccessor function to retrieve a desired message object or remotefunction call object. Continuing to a step 2228, the user can use theaccessor function of the object to select a desired payload object.

Proceeding to a step 2232, the user invokes a method of the payloadobject to get or set properties of the payload object. For, example, theuser can store data in the payload object. Next, at a step 2236, theuser invokes methods on the message object or the remote function callobject to send a communication. The user may also invoke other methodson a message object such as register the message such any broadcast onthe message is received by the invoking process. Other methods aredescribed above with reference to FIG. 5. Next, at a step 2240, the userimplements an event handler to receive asynchronous communications thatare received, if any.

FIG. 23 is a flowchart illustrating a process of using the studio module128. The studio module 128 provides a graphical user interface controlpanel for testing each of the communication interfaces that areidentified by the communication database 124, Starting at a step 2304, auser loads a selected communication database 124. A user may havedifferent communication databases for different projects. Once loaded, auser may view and select any of the communication interfaces in thecommunication database 124. After a is selected, the user can perform anumber of functions with respect to the database such as: designatingownership of a communication interface (step 2312), generating a dataset (state 2316), sending a field of information (step 2320), andsending a data set (step 2324).

FIG. 24 is a flowchart illustrating a process of generating a data setbased upon monitoring the communication between two threads executingunder the DAT system 100. It is noted that the process of generating adata set can be initiated by a user either: (i) the studio module 128,(ii) C language source code that invokes a method of the host computercommunication module 116, (iii) a script executing in the script engine312, or (iv) a COM-compliant application via the generated component508.

Starting at a step 2404, the user specifies the communication data pathsthat are to be traced. For example, the DAT system 100 can trace thatdata is sent via a message or via a remote function call.

Next, at a step 2408, the DAT system 100 monitors and stores the datathat is transmitted across each of the designated communication paths.In one embodiment of the invention, the data is stored in a persistenttest data object. Proceeding to a step 2412, any thread can then selectand retrieve the contents of any of persistent test data objects and usethe data for testing. Continuing to a step 2416, one of the threads ofthe DAT system 100 uses one of the persistent data object to transmitdata from one of the selected persistent data object across one of thecommunication data paths.

FIG. 25 illustrates an exemplary user interface 2500 that is provided bythe studio module 128. The user interface 2500 includes an interfacewindow 2504 that lists all of the interfaces that are maintained in thecommunication database 124. Each entry in the interface list isselectable by a user. In response to user selection, a communicationwindow 2508 is displayed on the screen. The communication window 2508includes an register icon 2510 that allows a user to register ownershipof a message or remote function call. In one embodiment, if a message isa two-way message, the communication window is divided into a commandwindow 2508 and a response window 2510. The command window and theresponse window include one or more data set fields 2512. The number ofdata set fields is configurable by the user. The data sets show thecontents of the most recent payload and a user configurable number ofpreviously received payloads.

Using the data set fields 2512, the user can build a payload for aparticular command message and set the payload of the response message.Furthermore, the user can select a “store data set” icon 2514 to storethe values in the data set fields 2512 in the communication database124. Later, the user can select a “load data set” icon 2516 to load thestored values. Furthermore, the user may select a clock icon 2518 tohave the studio module 128 automatically iterate and transmit the datavalues in sequence at a user configurable time interval.

FIG. 26 illustrates an exemplary user interface 2600 that allows a userto view and test the parameters that are transmitted as part of afunction call. Using a register icon, a user can register ownership of afunction. A user window 2608 displays a plurality of parameter fields2610 that allow a user to set the values of parameters in the function.An owner window 2610 displays the parameters that have been passed tothe function. The user interface 2600 allows the saving and loading ofdata sets as described above with reference to FIG. 25.

FIG. 27 is a flowchart illustrating a process of automaticallygenerating templates of source code for use with the embedded computercommunication module 112 or the host computer communication module 116.In one embodiment of the invention, the process of FIG. 27 is performedby the studio module 128. In another embodiment of the invention, theprocess of FIG. 37 is performed by a standalone tool, such as a codegenerator. For convenience of description, the following descriptionrefers to a code generator. However, it is to be appreciated that suchfunction could be provided by the studio module 128 or the communicationdatabase 124. Depending on the embodiment, additional steps may beadded, others removed, and the ordering of the steps rearranged.

Starting at a step 2704, the user identifies one or more interfacedefinition files that define the communication interface. For example,in code block 3200 of FIG. 32 illustrates a portion of an interfacedefinition file.

Continuing to a step 2708, the user selects one or more of thecommunication interfaces in the selected interface definition files. Inone embodiment of the invention, a code generator provides a graphicaluser interface utility for selection of the communication interfaces.

Next, at a step 2716, a code template of a “thread” is generated forhandling each of selected messages in the interface definition file. Anexemplary process of generating a thread is described below withreference to FIG. 28. An exemplary template is shown in code block 3204of FIG. 32.

Moving to a step 2720, a template of a thread is generated for each ofthe selected functions in the interface definition file. An exemplaryprocess of generating a thread is described below with reference to FIG.31. An exemplary template is shown in code block 3204 of FIG. 32.

FIG. 28 is a flowchart illustrating a process of generating a thread foreach of the identified messages in an interface definition file. FIG. 28illustrates in further detail the steps that occur in step 2716 of FIG.27. Depending on the embodiment, additional steps may be added, othersremoved, and the ordering of the steps rearranged.

Before starting at a step 2800, a message handling routine is created tohandle all messages that have been identified by the user. The messagehandling routine includes a loop and, subsequent to the loop, a switchstatement. See e.g., code block 3204. Starting at a step 2800, a loop isentered and steps 2804, 2808, and 2812 are performed for each of theidentified messages. Continuing to a step 2804, the code generator addsa line of code to register each of the messages. See e.g., code block3204. In one embodiment of the invention, the source code includes codeto invoke a registration routine that is provided by the embeddedcomputer communication module 112 or the host computer communicationmodule 116. The call to invoke the registration route is placed prior tothe generated switch statement.

Next, at a step 2808, the code generator generates message handling codefor each of identified messages. An exemplary process of generatingmessage handling code is described below with reference to FIG. 29.Continuing to a step 2812, the code generator creates routines forsending a message. An exemplary process of creating a routing forsending a message is described below with reference to FIG. 30.

FIG. 29 is a flowchart illustrating a process of generating messagehandling code. FIG. 29 illustrates in further detail the steps thatoccur in step 2908 of FIG. 28. Depending on the embodiment, additionalsteps may be added, others removed, and the ordering of the stepsrearranged. The process shown in FIG. 29 is performed with respect toeach of the messages identified by the user in step 2708 of FIG. 27.

Starting at a step 2904, the code generator generates a case statement.Proceeding to a step 2908, the code generator generates a comment to theuser to instruct the user to add code.

Proceeding to a decision step 2912, the code generator determineswhether the message is “two-way”. If the message is “two-way”, theprocess proceeds to a step 2916. Otherwise, the process proceeds to astep 2920.

At the step 2916, the code generator adds code in the generated casestatement to invoke a send response routine. As an example, code block3204 of FIG. 32 includes a call to the “SendMesessageTwoWayResponse”routine. The process of generating a response routine, such as the“SendMesessageTwoWayResponse” routine, is described below with referenceto 3016 of FIG. 30. In one embodiment of the invention, the generatedcode will invoke an API, e.g., SendResponse( ), of the DAT system 100.At this step, the code generator may also generate other APIs forconvenience of the user, e.g., routines to setup and attach pointers.Moving to a step 2920, the code generator may also generate code toinvoke a release routine that is provided by the API.

FIG. 30 is a flowchart illustrating a process of generating a templateof a routine for sending a message via the communication interfaceidentified by the user in step 2708 of FIG. 27. FIG. 30 illustrates infurther detail the steps that occur in step 2812 of FIG. 28. Starting ata step 3008, the code generator determines whether the message isone-way, two-way, or broadcast. If the message is one-way or two-way,the process proceeds to a step 3010. At the step 3010, the codegenerator generates a function to send a command to invoke a sendcommand. An exemplary generated code template is shown in code block3208 of FIG. 32. Continuing to a decision step 3012, the code generatordetermines whether the communication is one-way or two-way. If themessage is not one-way, i.e., two-way, the process proceeds to a step3016. At the step 3016, the code generates a function for sending aresponse. The generated code invokes the API to send a response.

Referring again to the decision step 3008, the code generator determineswhether message is a broadcast message. If the message is a broadcast,the process proceeds to a step 3020. At the step 3020, the codegenerator adds code to invoke an broadcast routine that is part of theAPI of the embedded computer communication module 112 and the hostcomputer communication module 116. From steps 3012 (if the communicationis “one-way”), 3020, and 3016 the process proceeds to a step 3024. Atthe step 3024, the code generator determines whether there are pointerspresent in the payload of the message. If pointers are present, theprocess proceeds to a step 3028. At the step 3028, the code generatorgenerates code to invoke a pointer setup command that is part of thecommunication library API. Next, at a step 3032, the code generatorgenerates code to invoke the API attach pointer. It is noted that thegenerated commands during steps 3032 and 3028 are inserted into thegenerated code prior to the generated send response command (step 3016).

FIG. 31 is a flowchart illustrating a process of generating templatecode for communicating across platforms via a remote function call. Inone embodiment of the invention, inter-platform function calls invoke alocal function that communicates with the remote function of the samename via messaging that is provided by the embedded computercommunication module 112 and the host computer communication module 116.

Depending on the embodiment, additional steps may be added, othersremoved, and the ordering of the steps rearranged. Starting at a step3104 a loop is performed with respect to steps 3108, 3112, and 3116. Inthe loop, template code is generated for exestuation on a localplatform, i.e., either the embedded computer 104 or the host computer108. The local platform in this context is defined to be the computerthat does not have the routine that is to be invoked. Steps 3108, 3112,and 3116 are performed with respect to each of the functions identifiedby the user in step 2708 of FIG. 27. At the step 3108, the codegenerator generates a send command. Next, at a step 3112, the codegenerated generates a read command. Proceeding to a step 3116, the codegenerator generates code to return a response. An exemplary code blockresulting from steps 3108, 3112, and 3116 is shown in code block 3212 ofFIG. 33.

Next, at a step 3120, a loop is performed with respect to steps 3124,3128, 3132, 3136, and 3140. In this loop, template code is generated forexecution on the remote platform. Proceeding to a step 3124, the codegenerator generates code to invoke a registration routine of the API.Moving to a step 3128, the code generator generates code that invokesthe local API that was requested by the thread on the other platform andsends a response message. An exemplary code block resulting from steps3124, 3218, 31332, 3136, and 3140 is shown in code block 3214.

Next, at a decision step 3132, the code generator determines whetherthere are any pointers in the parameters of the function. If there areno pointers in the parameters of the function, the process ends.However, if there are pointers, the process proceeds to a step 3136 andthe code generator generates code to invoke the API to setup a pointer.Moving to a step 3140, the code generator generates code to invoke theAPI to attach a pointer. The process then ends.

FIG. 34 is a flowchart illustrating a process of generating and usingcode to intercept selected routines executing on a target device, e.g.,the embedded computer 104. At this step, in one embodiment, a user hasdeveloped a plurality of source code files that are targeted to becompiled and executed on the embedded computer 104. The process of FIG.34 may be performed to allow the host computer 108 to intercept a callof one of the routines on the embedded device 104 to another of theroutines on the embedded device 104. After intercepting the call, thehost computer 108 may perform exemplary actions such as: (i) allowing auser to view and analyze the data; (ii) call the intercepted routine onthe embedded computer 104 and forward the results to the invoker of theroutine; and/or (iii) for purposes of future use and diagnostics, storethe parameter information that is provided by the invoker of the routineand/or store the return information that is passed to invoker of theroutine. Depending on the embodiment, additional steps may be added,others removed, and the ordering of the steps rearranged.

Starting at a step 3404, interception code is generated for one or moreselected modules. In one embodiment, at step 3404, in response to theselection of a particular module (a set of routines) by a user, the usercan define the type of interception that will be done with respect tothe subject module. The module is targeted to be executed on a targetdevice such as the embedded computer 104. At this step, the user candefine among other items discussed below the following: (i) whether thehost computer 108 will invoke the a routine in the embedded computer104; (ii) whether the routine will be provided on the host computer 108instead of the embedded computer 104; or (iii) whether the user requeststhe capability to dynamically intercept the invocation of a selectedroutine on the target device. An exemplary process of generatinginterception code is described below with respect to FIG. 35. Dependingon the selections of the user, code is generated for execution on boththe host computer 120 and the embedded computer 104.

In one embodiment, step 3404 is performed by a code generation module.In one embodiment, the code generation module may be integrated with thestudio module 128. In another embodiment, the code generation module maycomprise a standalone application (not shown) executing on the hostcomputer 108.

Continuing to a step 3408, the code that is generated is generated instep 3404 is compiled with the module(s) selected in step 3404 to createan executable program. Next, at step 3412, the coded that was compiledin step 3404 is executed on the host computer 108 and/or the embeddedcomputer 104.

Moving to a step 3416, the embedded computer 104 optionally providestrace information to the host computer 108 for viewing and/or storagecapture. In one embodiment, the trace information includes parametersand/or return information that is passed to or returned from routinesexecuting on the embedded computer 104. The trace information may bestored in a log in the embedded computer 104 and periodically requestedby the host computer 108.

Next, at a step 3420, the host computer 108 can dynamically interceptselected functions executing on the embedded computer 104. In oneembodiment, a graphical user interface is provided by the studio module128 to allow a user to send a signal to the embedded computer 104requesting that one or more selected functions executing on the embeddedcomputer 104 be intercepted. In another embodiment, the signal isprovided by a scripting language. In yet another embodiment, the signalis sent by an application program. In response to this signal and uponinvocation of the routine to be intercepted, the embedded computer 104gathers the parameters that have been provided for the routine to beintercepted and transmits the gathered parameters to the host computer108 for processing. Once the host computer 108 has finished processingthe intercepted routine, the host computer 108 provides returninformation to the embedded computer 104 for returning to the routinethat called the intercepted routine. In one embodiment, the parameterinformation that is transmitted from the embedded computer 104 to thehost computer 108 is modified via the data adaptation process describedabove with respect to steps 1116, 1124, and 1128 of FIG. 11.Furthermore, in one embodiment, the return information that istransmitted from the host computer 108 to the embedded computer 104 ismodified via the data adaptation process described above with respect tosteps 1116, 1124, and 1128 of FIG. 11.

In one embodiment, a user may also request to dynamically halt theinterception of a particular routine. In this embodiment, a request maybe asynchronously sent from the host computer 108 to the embeddedcomputer 104 requesting that a call to the intercepted/routine proceedwithout interception.

Next, at a step 3424, a user may optionally request to reuse the traceinformation gathered at step 3412 (step 3404). In one embodiment, theuser may use the parameter sets/and or return information gathered atstep 3424 and provide this information to routines executing on the hostcomputer 108 or the embedded computer 104.

FIG. 35 is a flowchart illustrating a process of generating interceptioncode. FIG. 35 illustrates in further detail certain steps that occur inone embodiment with respect to step 3404 of FIG. 34.

Starting at a step 3508, the code generation module receives datacapture instructions from the user. In one embodiment, as part of thisstep, the user defines for one or more modules which routines are to beintercepted and how they are to be intercepted. In one embodiment, oneor more of three different types of interceptions can be selected:“stub”, “proxy”, or “delegate.” A stub enables host computer 108 to beable to invoke the respective method on the embedded computer 104. Aproxy enables embedded computer 104 to be able to invoke a method of thesame name that is executing on the host computer 108 or anotherplatform. A delegate intercepts a call to a selected function. For eachof the type of interceptions, i.e., stub, proxy, or delegate, sourcecode is automatically generated by the code generation module to performthe respective functions. For convenience of description, the generatedsource code for each type of interception is referred to by itsrespective type, e.g., a stub comprises the code that is used to performthe “stub” interception described above.

In one embodiment, a graphical user interface 3900 is provided thatdisplays each of the routines that is located within a selected moduleof source code. As is shown in FIG. 39, a plurality of routines, e.g.,“DevInit” and “DevRun.”, in a selected module are displayed. For each ofthe routines, a user can designate the routine as “Stub”, “Proxy”, or“Delegate.” In one embodiment, valid combinations of selections comprisethe following: no boxes checked, stub only, proxy only, delegate only,and stub and delegate.

Continuing to a step 3516, the code generation module, depending on theuser's selections, generates one or more proxies in the source code ofthe user-selected modules. An exemplary process of creating a proxy isdescribed below with reference to FIG. 36. Next, at a step 3520, thecode generation module, depending on the user's selections, generatesone or more stubs. As part of generating a stub, code is generated forexecuting on the client device receive a call from the host computer108. Proceeding to a step 3524, the code generation module, depending onthe user's selections, generates one or more delegates in the in theuser-selected source code modules. An exemplary process of creating adelegate is described in further detail below with reference to FIG. 37.

FIG. 36 is a flowchart illustrating a process of generating a proxy thatoccurs in one embodiment during the process of FIG. 35. Depending on theembodiment, additional steps may be added, others removed, and theordering of the steps rearranged.

As part of initial setup, the code generation module provides a newproxy routine having the name as the original routine. Thus, aftercompilation, when other routines invoke the stub routine, they will callthe new proxy routine instead of the original routine. At a step 3604,the code generation module provides code to collect the parameters thatwere passed. Next, at a step 3608, the code generation module includescode to build a message to send the parameters to the host computer 108.Continuing to a step 3612, the code generation module provides code totransmit the message. Moving to a step 31616, the code generation modulegenerates code to wait for a response and copy the output. Next, at astep 3620, the code generation module provides code to return the out tothe routine that invoked the routine.

FIG. 37 is a flowchart illustrating a process of generating code tointercept a routine that executed by a target device. Depending on theembodiment, additional steps may be added, others removed, and theordering of the steps rearranged. In one embodiment, as a preparatorystep, the code generation provides a source code framework for aninterception routine, e.g., provides begin and end tokens for theroutine and provides the name of the routine. In one embodiment, thename of the interception module is the same name as the selectedroutine. In this case, the name of the intercepted routine is renamed toa new name. This advantageously eliminates the need to modify theroutines that call the intercepted routine. In another embodiment, theroutines that invoke the intercepted routine (the delegate routine) aremodified to invoke the interception module. Advantageously, this isuseful if the source code for the intercepted function is not available.In addition, in one embodiment, as a preparatory step, the codegeneration provides a source code framework for an interception routine,e.g., provides begin and end tokens for the routine and provides thename of the routine.

Starting at a step 3704, the code generation module generates code inthe delegate interception code for “dynamic override.” As part of thisstep, in one embodiment, the code generation engine generates code thatdetermines whether the host computer 108 has signaled to intercept therespective delegate function. Continuing to a step 3712, the codegeneration module generates code that is configured to be executed ifthe user has requested that the call not be intercepted. At step 3712,the code generation module 3712 generates code to collect traceinformation before the call to intercepted function. In one embodiment,the generation of code to collect trace information is selectablyenabled or disabled by a user. In another embodiment, a determination ofwhether to collect trace information is determined at runtime by anapplication on the host computer 108, e.g., a scripting program, thestudio module, or a Windows application.

Continuing to a step 3716, the code generation module generates code toinvoke the intercepted module. Proceeding to a step 3720, the codegeneration module generates code to collect trace information, e.g.,return information, after the call to the intercepted function. It isnoted that in one embodiment the trace information is stored in a logfile whose contents may be requested by the host computer 108.

The DAT system 100 provides a single virtual environment that enablesthreads to be located on different platforms and still seamlesslycommunicate with each other. The DAT system 100 provides communicationinteroperability between the two platforms by automatically transformingthe data depending on the machine characteristics of the embeddedcomputer 104, the host computer 108, and the communication interfacesthat are stored in the communication database 124. The DAT system 100provides automatic and seamless access to the message-based and remotefunction call interfaces designed into the embedded computer's softwareapplication. The DAT system 100 automatically extracts interfaceinformation and builds a database of messaging and remote function callinformation.

Using the studio module 128, a user has complete visibility and controlof the embedded application's interfaces without having to address thefollowing issues: (i) updates to a desktop tool to accommodate newmessages; (ii) updates to the embedded software to support the desktoptool's new functionality; (iii) what target compiler is used; (iv) whatRTOS is used; and (iv) what platform the thread(s) are executing on. TheDAT system 100 allows seamless access to interfaces stored in thecommunication database 124 via scripting languages or any COM-compliantapplication.

While the above detailed description has shown, described, and pointedout novel features of the invention as applied to various embodiments,it will be understood that various omissions, substitutions, and changesin the form and details of the device or process illustrated may be madeby those skilled in the art without departing from the spirit of theinvention. The scope of the invention is indicated by the appendedclaims rather than by the foregoing description. All changes which comewithin the meaning and range of equivalency of the claims are to beembraced within their scope.

1. A method comprising: transmitting a request from a host device to a target device to intercept a call from an invoking routine to an invoked routine; intercepting the call; collecting at least one parameter that is provided as part of the call to the invoked routine; transmitting the parameter from the target device to the host device; and modifying the parameter based upon a characteristic of the host device and the target device. 